fix(console): type-check tsconfig.node.json and wire it into the gate (#3305) - #3383

…#3305)

apps/console/tsconfig.node.json is the project covering vite.config.ts, and
nothing ran it: `build` is `tsc && vite build && …`, and plain `tsc` reads
tsconfig.json without building project references. The file deciding how the
console is bundled was the one file in the app no gate read, and it had
accumulated 7 standing errors (5 at the issue's baseline, plus 2 more from
scripts/vite-maplibre-worker.ts landing since).

Three defects, fixed at their source:

- `compression({ algorithm })` -> `algorithms: [...]`. The singular key is not
  in vite-plugin-compression2's ViteCompressionPluginOption and was never read
  at runtime either; it fell through to the plugin default, which is BOTH
  `['gzip', 'brotliCompress']`. So each of the two instances compressed every
  asset twice. The .gz/.br pair that made the build look correct came from the
  default, not from these options. Artifact set is unchanged (449 .gz + 449
  .br, byte-identical file list before and after); the duplicated work is gone.
- scripts/vite-*.ts were unresolvable from this project (TS6307 + TS2307).
  They stay in scripts/ — a deliberate root-level location the root vitest
  project already covers via `scripts/**/*.test.ts` — and instead the root
  package.json now declares the `vite` it imports, matching how it already
  declares console's other Vite plugins (vite-plugin-compression2,
  rollup-plugin-visualizer). Root and apps/console resolve the identical
  vite@8.2.0 install, so `Plugin` stays one type.
- `defineConfig` now comes from `vitest/config`, so the `test` block (merged
  into vitest.config.ts) is typed instead of falling outside UserConfigExport.

Wiring, which is the point of the issue: console's `type-check` now also runs
`tsc -b tsconfig.node.json --force`. `--force` is load-bearing — without it the
build-mode up-to-date check skips the project when only dependencies changed,
which silently reported green while `vite` was unresolvable.

The project emits to a gitignored cache dir rather than `noEmit`, because
tsconfig.json references it and a referenced project that disables emit is
TS6310; left at the default it littered .js/.d.ts beside every input.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GTRjn8xBqp75dk7kFupVRt

…3305)

Wiring the tsconfig.node.json project into `type-check` is only half a gate if
`pnpm type-check` can serve a cached green for it. `type-check` declared no
`inputs`, so turbo hashed only each package's own files — and the project this
gate added reads `scripts/vite-*.ts`, which live at the repo root, inside no
package.

Measured before this change: breaking `scripts/vite-crypto-stub.ts` left
`@object-ui/console:type-check` on the identical hash 9b56b04fee5b19cc,
"cache hit, replaying logs", turbo exit 0 — while running the same script
directly reported TS2322. CI restores a turbo cache across runs
(`restore-keys: turbo-${{ runner.os }}-type-check-`), so that stale green was
reachable there, not just locally.

With `$TURBO_ROOT$/scripts/vite-*.ts` added to the task's inputs, the same
experiment gives a different hash (14b3af20777c366d), "cache miss, executing",
and turbo exit 1 with the real error; restoring the file returns a cache hit on
the original hash. `$TURBO_DEFAULT$` is listed first so nothing is narrowed.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GTRjn8xBqp75dk7kFupVRt